<?php
/**
 * <https://y.st./>
 * Copyright © 2016 Alex Yst <mailto:copyright@y.st>
 * 
 * This program is free software: you can redistribute it and/or modify
 * it under the terms of the GNU General Public License as published by
 * the Free Software Foundation, either version 3 of the License, or
 * (at your option) any later version.
 * 
 * This program is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
 * GNU General Public License for more details.
 * 
 * You should have received a copy of the GNU General Public License
 * along with this program. If not, see <https://www.gnu.org./licenses/>.
**/

$xhtml = array(
	'<{title}>' => 'Repairs were needed on the weblog index',
	'<{body}>' => <<<END
<p>
	We ended up not going to Springfield today, though Vivian did go home at the end of the day.
</p>
<p>
	The new calendar year page in the weblog directory of this website brought with it several bugs.
	Most of them were caused by stupid oversights on my part, but it turns out that one of my base functions I built also has a flaw.
	I consider this error to be caused by $a[ISO]-8601.
	This specification idiotically labels Sunday as the final day of the week instead of the first.
	$a[PHP]&apos;s <a href="https://secure.php.net/manual/en/function.date.php"><code>date()</code> function</a> has the ability to use $a[ISO]-8601 week numbers, but does not otherwise have any options for distinguishing one week from another.
	Because of this, I used the $a[ISO]-8601 week numbers when building my function and shifted all Sundays one week forward.
	Normally, this would put Sundays within the appropriate week.
	However, I did not account for the new year corner case.
	Specifically, the Sunday supposedly within the week that the year ended is not shifted into the first full week of the year, but is instead shifted into an imaginary week with a week number one higher than the highest real week number.
	This issue may not be present once I shift my code away from using timestamps, but for now, I have repaired the function so instead of simply adding one to the week number of every Sunday, it instead looks ahead and matches the week number of the Sunday to the following Monday&apos;s week number.
</p>
<p>
	After putting my new error handling function into effect, I ran into a bunch of errors relating to the use of dates.
	Specifically, the option to tell the <a href="https://secure.php.net/manual/en/function.mktime.php"><code>mkdate()</code> function</a> if daylight savings time is in effect is deprecated.
	I had always set daylight savings time to not be in effect because daylight savings time is a pain to code around.
	Without that option available, I simply removed it hoping for the best.
	This, however, messed up all entry numbers involving dates that fell within daylight savings time, causing them to become non-integers due to that one hour difference between the time stamps that were expected and those that were received.
	I managed to hack together a fix, but it is only a hack.
	The only clean option is to ignore daylight savings time, as it only throws things off and that level of precision is not needed or wanted.
	Of course, if the world was not idiotically setting their clocks forward and backward each year, $a[PHP] would not be imitating this nonsense and there would be no issue to build around.
</p>
<p>
	I started work on the onion address-finding spider again, this time adding a timeout feature to work around this one page that never finishes loading.
	Seriously, last time I ran my spider script, I waited hours and the spider could not get past this one page.
	It could not have been continually sending data like a huge page, as the spider did not hit the download limit and abort.
	I also increased the download length limit in the configuration of my own copy of the spider in hopes of getting a different page to download successfully.
	This page is huge, but it is a regular Web page containing only a multitude of hyperlinks.
	At the time I went to bed, the spider had not completed its crawl, but it seemed to have made great progress.
	Unless there is an unexpected error, I expect it to complete tomorrow.
</p>
<p>
	I started work on a couple new wrapper classes while waiting for the spider to finish its task, but I did not complete them.
	Due to the <a href="https://secure.php.net/manual/en/ref.fbsql.php">FrontBase functions</a> having two types of resources to work with, the two classes are a bit entangled and one should not be considered completed until the other is.
	For one of the classes, I experimented with class constants and a switch statement.
	I decided that due to the way type juggling is implemented in $a[PHP], I thought it best to avoid including one and zero in the list of integer values used by the constants.
</p>
<p>
	My <a href="/a/canary.txt">canary</a> still sings the tune of freedom and transparency.
</p>
<section id="docmod">
	<h2>Document modifications</h2>
	<p>
		On <a href="/en/weblog/2018/01-January/16.xhtml#Vivian">2018-01-16</a>, my sister, Vivian, requested that I replace all instances of her legal name in my journal with the name &quot;Vivian&quot;.
		She also asked that the name of the organisation she works for be redacted.
		This page was modified to fulfil that request.
	</p>
</section>
END
);
